Electronic files, such as, for example, messages, data packets, etc., are generally created by a user and then sent electronically to an endpoint. For example, the user may create a message that is produced by a message production service of a message processing system. The message is sent along a workflow of the message processing system to a message publishing service of the message processing system that publishes the message. The publishing service may provide the message to a database for storage, may provide the message to another entity that may change state based upon the message or some perform some other function, may provide the message to another user, etc.
Often, such messages may have attributes or conditions that need to be satisfied for the message to be valid. For example, a message may only be relevant or valid if it arrives at a particular time or on a particular day. Thus, while the message may be generated and sent early enough to arrive by the appropriate time or day, due to various issues such as, for example, workload of the message processing system over which the message is being sent, available bandwidth, size of the message and any attachments, error rate, etc., the message may not arrive by the desired time or day. Thus, it is difficult and costly to predict how long it may take for a message to travel along the workflow from a starting point to an end point.
In order to alleviate delays in receipt of messages, it is common practice to validate a message as early as possible along the workflow of the transmitted message, e.g., the workflow of moving the message from a starting point to an endpoint. This validation process verifies that attributes of the message are correct and do not violate preset rules. However, as previously noted, by the time the message reaches the endpoint, the message may no longer be valid due to one or more attributes not meeting predetermined criteria, e.g., the message arrives late. Thus, a second validation process is often included in the workflow at or just prior to the endpoint of the workflow. This second validation process verifies that the message is valid and does indeed satisfy the predetermined criteria. If the message satisfies the predetermined criteria, then the message is passed along to the message publishing service at the endpoint.
However, if the message does not satisfy the predetermined criteria, then the message is ignored and/or discarded and an error message may be sent to the starting point, e.g., the message production service, and/or to the user that sent the message. Rejected messages incur additional computing resource costs, such as processing delays, troubleshooting and message republishing. Generally, the cost of failure is proportional to the computation resources dedicated to the message prior to the rejection of the message. Furthermore, the inclusion of two duplicative validation processes increases operation costs. Additionally, it currently is too expensive or even impossible to change messages at the endpoint of the workflow, e.g., just prior to the message publishing service. Changing of messages just prior to the message publishing service requires extra business logic to perform the validation and changing of the messages. More particularly, validation just prior to the message publishing service may be costlier, or even impossible, for example, due to the computational cost of making calls to other services, the cost of accessing business logic or security restrictions in the message publishing environment. Furthermore, some devices at the endpoint of the workflow may be “dumb” devices incapable of validating and/or changing messages, as well as only being capable of unidirectional communications, e.g., receiving communications.
The disclosure made herein is presented with respect to these and other considerations.